Method for moving rights object and method for managing rights of issuing rights object and system thereof

ABSTRACT

Disclosed is a method for managing rights of issuing a Rights Object (RO), and a method for moving an RO created by a Local Rights Manager (LRM) between Digital Rights Management (DRM) Agents. A Right Issuer (RI) permits an LRM to move an RO created (or issued) by the LRM to move via the RI, and a first DRM Agent moves the RO to a second DRM Agent via the RI.

TECHNICAL FIELD

The present invention relates to a Digital Rights Management (DRM), andmore particularly, to a method for moving a Rights Object (RO), a methodfor managing rights of issuing an RO, and a system thereof.

BACKGROUND ART

Generally, a Digital Rights agent (DRM) is technique to protect a rightsobject (RO) for digital contents and systematically manage it, andprovides a protecting and managing scheme for preventing an illegal copyof the contents, obtaining the RO, creating/moving the contents, andconsuming the RO and the contents. The DRM is applied to variousapplications such as a media player, an audio player, or an imageviewer.

FIG. 1 is a configuration view showing a DRM system in accordance withthe related art. As shown, the DRM system controls contents issued to auser by a content provider to be consumed only in a right-limit of RO.The content provider is an entity corresponding to a Contents Issuer(CI) or a Rights Issuer (RI).

The CI issues contents protected by a specific encryption method(hereinafter, will be referred to as DRM contents) so as to protectcontents from a user having no access right, and the RI issues a RightsObject (RO) necessary to consume the DRM contents.

A DRM agent is mounted at a device thus to receive the DRM contents andROs from the CI or the RI, and controls consumption of the DRM contentsby analyzing a ‘License’ contained in the RO, and by converting the DRMcontents to contents that can be consumed at a corresponding DRM Agent.

FIG. 2 is a block diagram showing a state that a Rights Object (RO) ismoved between DRM Agents via an Right Issuer (RI).

Referring to FIG. 2, a first DRM Agent may consume an RO issued from anRI by a certain amount, and then transfer (move) the RO to a second DRMAgent via the RI. The first DRM Agent requests the RI to move the RO tothe second DRM Agent, and transfers the RO to the RI (or deletes theRO). The RI responds to the request, and transfers the RO to the secondDRM Agent by using an RO Acquisition protocol with the second DRM Agent.

FIG. 3 is a schematic block diagram showing a state that an RO and a DRMcontent that can be user by a DRM Agent is imported to the DRM Agent viaa Local Rights Manager (LRM).

Referring to FIG. 3, a DRM content and an RO (or license) that have beenprotected by an external DRM System, may be imported (changed) that canbe used by a DRM Agent, via a Local Rights Manager (LRM). The reason isbecause a DRM content and an RO having been received from an externalDRM system can not be used at a DRM system having a different standard.Accordingly, a DRM content having been received from a DRM system havinga different standard is imported to the LRM. The Imported RO may betransferred to a DRM Agent from the LRM. However, there is a technicallimitation in that the DRM Agent can not transfer the Imported RO toanother DRM Agent.

DISCLOSURE OF THE INVENTION

Therefore, it is an object of the present invention to provide a methodfor moving a Rights Object (RO or license) imported by a Local RightsManager (LRM) to a second DRM Agent from a first DRM Agent, and a methodfor managing rights of issuing RO.

To achieve these objects, there is provided a method for moving RightsObject (RO), comprising: sending, by a First Entity, a RegistrationRequest Message including first information about moving of an RO, to aSecond Entity; receiving, by the First Entity, a Registration ResponseMessage including second information about moving of an RO, from theSecond Entity; importing, by the First Entity, an RO and a DRM contentfrom digital contents received from an external system; and moving, bythe First Entity, the Imported RO to a DRM Agent.

The method further comprises receiving, by the First Entity, a TriggerMessage for a protocol to be registered to the Second Entity, from theSecond Entity.

To achieve these objects, there is also provided a method for managingrights of issuing Rights Object (RO), comprising: receiving, by a SecondEntity, a Request Message about moving of an RO created by a FirstEntity, from the First Entity; checking, by the Second Entity, whetherfirst information about moving of an RO has been included in the RequestMessage; and when the Second Entity permits moving of an RO, sending, bythe Second Entity, a Response Message including second information aboutmoving of an RO, to the First Entity.

Preferably, the method further comprises: checking, by the SecondEntity, whether a RequestToMoveRO parameter has been included in theRequest Message; and storing, by the Second Entity, an ID of the FirstEntity.

Preferably, the method further comprises: receiving, by the SecondEntity, from a first DRM Agent a Request Message about moving of an ROto a second DRM Agent; extracting, by the Second Entity, an ID of theFirst Entity included in the Request Message; checking, by the SecondEntity, whether the stored ID of the First Entity is consistent with theextracted ID of the First Entity; when the two IDs of the First Entityare consistent to each other, sending, by the Second Entity, theResponse Message, to the first DRM Agent; and moving, by the SecondEntity, the RO to the second DRM Agent.

To achieve these objects, there is still also provided a method formoving an imported Rights Object (RO), comprising: receiving, by a firstDRM Agent, an RO from a Local Rights Manager (LRM), wherein the RO isobtained from contents imported by the LRM from an external system;sending, by the first DRM Agent, an RO Moving Request Message, to anRights Issuer (RI) so as to move the RO to the second DRM Agent; andreceiving, by the first DRM Agent, a Response Message about the ROMoving Request Message, from the RI.

The present invention has the following effects.

Firstly, since a new protocol and information for moving an RO (elementor parameter) are defined between the RI and the LRM, an RO created bythe LRM can be safely moved between the first and second DRM Agents.

Secondly, through the new protocol and information for moving an RO(element or parameter), rights of issuing an RO imported by the LRM canbe effectively managed.

Thirdly, since the DRM Agent can move not only an RO issued from the RI,but also an RO imported from an external DRM system, to other DRM Agent,a user's convenience in using digital contents can be enhanced.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a configuration view showing a Digital Rights Management (DRM)system in accordance with the conventional art;

FIG. 2 is a block diagram showing a state that a Rights Object (RO) ismoved between DRM Agents via a Right Issuer (RI);

FIG. 3 is a schematic block diagram showing a state that an RO and a DRMcontent that can be user by a DRM Agent are imported to the DRM Agentvia a Local Rights Manager (LRM);

FIG. 4 is a block diagram showing a method for moving an Imported ROaccording to a first embodiment of the present invention; and

FIG. 5 is a flowchart showing a method for moving an Imported ROaccording to a first embodiment of the present invention.

MODES FOR CARRYING OUT THE PREFERRED EMBODIMENTS

Reference will now be made in detail to the preferred embodiments of thepresent invention, examples of which are illustrated in the accompanyingdrawings.

The present invention is applied to a Digital Rights Management (DRM)system. However, the present invention is not limited to the DRM system,but may also be applied to all communications systems and methodsthereof to which the technical scope of the present invention may beapplied, and other copyrights related system and method thereof.

Various modifications and embodiments can be made in the presentinvention, and reference will be made in detail to the preferredembodiments of the present invention, examples of which are illustratedin the accompanying drawings. However, it should also be understood thatembodiments are not limited by any of the details of the foregoingdescription, but rather should be construed broadly within its spiritand scope and it is intended that the present invention covermodifications and variations of this invention provided they come withinthe scope of the appended claims and their equivalents.

Though terms including ordinal numbers such as a first, a second, etc.may be used to explain various components, the components are notlimited to the terms. The terms are used only for the purposed ofdistinguishing one component from another component. For instance, afirst component may be referred to as a second component, or similarly,the second component may be referred to as the first component, withoutdeparting from the scope of the present invention. A term ‘and/or’ isused to include a combination of a plurality of disclosed items or oneof the items.

In case it is mentioned that a certain component is “connected” or“accessed” to another component, it may be understood that the certaincomponent is directly connected or accessed to the another component orthat a component is interposed between the components. On the contrary,in case it is mentioned that a certain component is “directly connected”or “directly accessed” to another component, it should be understoodthat there is no component therebetween.

Terms used in the present invention is to merely explain specificembodiments, thus it is not meant to be limiting. A singular expressionincludes a plural expression except that two expressions arecontextually different from each other. In the present invention, a term“include” or “have” is intended to indicate that characteristics,figures, steps, operations, components, elements disclosed on thespecification or combinations thereof exist. Rather, the term “include”or “have” should be understood so as not to pre-exclude existence of oneor more other characteristics, figures, steps, operations, components,elements or combinations thereof or additional possibility.

Except that they are not differently defined, all terms used in thepresent invention including technical or scientific terms have the samemeanings with terms that are generally understood by those skilled inthe art related to the field of the present invention. The terms same asthose of which are defined in a general dictionary should be understoodthat the terms have meanings same as contextual meanings of the relatedart. And, as long as the terms are not definitely defined in the presentinvention, the terms are not interpreted as ideal or excessively formalmeanings.

Reference will now be given in detail to the preferred embodiments ofthe present invention, examples of which are illustrated in theaccompanying drawings. Wherever possible, the same reference numeralswill be used through the drawings to refer to the same or similar parts,and the same descriptions thereof are omitted.

The basic concept of the present invention is that an RO created(imported) by a Local Rights Manager (LRM) is transferred (moved) to aspecific DRM Agent (for convenience, a first DRM Agent), and then theImported RO is transferred (moved) to another DRM Agent (forconvenience, a second DRM Agent) via a Rights Issuer (RI). For this, (1)a new protocol (LRM_RI Registration Protocol) between the LRM and the RIis defined, (2) newly added defined information (e.g., parameter) isused when the LRM imports an RO, (3) when receiving a request of movingthe RO from the first DRM Agent, and when performing the LRM_RIRegistration Protocol, the RI moves the RO to the second DRM Agent basedon stored information.

In the present invention, a new protocol (LRM_RI Registration Protocol)is defined between the LRM and the RI, and new information (parameter),a RequestToMoveRO, an OkayToMoveRO, etc. are defined. The new protocoland the parameter will be explained in more detail.

Hereinafter, the terms used in the present invention will be explained.

LRM is an entity that is responsible for aspect(s) of Import and it mayalso manage an Imported-Content for a limited group of OMA DRM Agents.Also, the LRM is an entity that manages an imported content (e.g., DRMcontent) for a specific group to which DRM Agents belong. Here, the‘Import’ has a meaning of converting Import-Ready Data into OMA (P)DCFsand ROs.

Certificate Authority (CA) is an entity that performs functions relatingto certification of entities, contents, etc.

The ROs for DRM contents are divided into a Stateful RO and a StatelessRO. The Stateless RO is an RO that a DRM Agent does not manage StateInformation. The Stateful RO is an RO that a DRM Agent manages StateInformation so as to precisely utilize a Permission and a Constraintinside the RO. The Constraint managed by the State Information includes‘interval’, ‘count’, ‘timed-count’, ‘accumulated’, etc. The StateInformation indicates a usable amount of RO, and one State Informationis managed by one Stateful RO. The State Information may be managed in amanner of ‘count’, ‘timed-count’, etc., or in a manner of ‘remainingcount’, ‘remaining interval’, etc. State Information may be a set ofvalues representing a current sate associated with Rights. It is managedby the DRM Agent only when the Rights contain any of the StatefulConstraints (e.g., interval, count, timed-count, accumulated, etc.).

The DRM Agent (or device) indicates all types of devices that canperform technical features of the present invention. That is, the DRMAgent of the present invention receives an RO (RO imported by the LRM),and moves the Imported RO to another DRM Agent via the RI. The DRM Agentincludes all types of mobile communication terminals (e.g., UserEquipment (UE), portable terminal, mobile phone, DMB phone, game phone,camera phone, smart phone, etc.), a notebook, a desktop computer,Personal Digital Assistants (PDA), so-called white home appliances, etc.These devices receive an RO imported by an LRM, transmit the Imported ROto another DRM Agent via an RI, and receive the RO from the RI.

The DRM Agent of the present invention may be configured as onecomponent of a device as a module that performs functions relating tomanagement of digital contents, e.g., software and hardware devices.Hereinafter, the terms of ‘DRM Agent’ and ‘Device’ will be considered tohave the same meaning.

Hereinafter, preferred embodiments of the present invention will beexplained in more detail with reference to the attached drawings. Thesame reference numerals will be given to the same parts or correspondingparts, and their detailed explanations will be omitted.

FIG. 4 is a block diagram showing a method for moving an Imported ROaccording to a first embodiment of the present invention.

As shown in FIG. 4, the system comprises a Certificate Authority (CA)100, a Rights Issuer (RI) 200, a Local Rights Manager (LRM) 300, a firstDRM Agent 400 (or first device), and a second DRM Agent 500. The CA 100provides a certificate to the RI 200, the LRM 300, the first DRM 400,and the second DRM 500. Here, the certificate of the CA serves as acommon root certificate. For instance, processes to issue a certificateby the CA 100 are based on a well-known X.509 based-process, and itsdetailed explanation will be omitted.

Referring to FIG. 4, a newly defined protocol between the RI 200 and theLRM 300 (e.g., LRM_RI Registration Protocol) serves as a signalingbetween the RI 200 and the LRM 300 so that an RO created by the LRM 300can be moved, by the first DRM Agent 400, to the second DRM Agent 500via the RI 200 (S10).

Then, the LRM 300 imports the RO received by the LRM 300 from anexternal system (or DRM Agent) (S20). Here, the Imported RO is an ROcreated and issued by the LRM 300 by matching an RO of another standardformat with a standard format of the present invention. The Imported ROis defined so as to be distinguished from the RO received by the LRM 300from an external system.

The LRM 300 moves an Imported RO to the first DRM Agent 400 through anLRM_Agent_RO Moving Protocol (S30). Once the first DRM Agent 400requests the RI 200 of moving the Imported RO to the second DRM Agent500, by performing an ROAP_RO Moving Protocol (S40), the Imported RO ismoved to the second DRM Agent 500 from the RI 200 (S50).

FIG. 5 is a flowchart showing a method for moving an Imported ROaccording to a first embodiment of the present invention, whichexplained FIG. 4 in more detail.

FIG. 5 shows a method for requesting, by the RI 200, an Imported RO (ROcreated from the LRM 300) from the first DRM Agent, and then moving tothe second DRM Agent. The method comprises: registering, by the LRM 300,to the RI 200 through an LRM_RI_Registration Protocol (S10); importing,by the LRM 300, an RO received (or acquired) from another DRM system(S20); moving, by the LRM 300, the Imported RO, to the first DRM Agent400 through an LRM_Agent RO Protocol (S30); moving, by the first DRMAgent 400, the Imported RO and State Information, to the RI 200 througha ROAP_RO Moving Protocol (S40); and issuing the RO by using an ROAcquisition Protocol (e.g., the conventional 1-pass or 2-pass ROAcquisition Protocol, or 3-pass Confirmed RO Acquisition Protocol).These steps S10 to S50 will be explained in more detail.

The LRM 300 requests the RI 200 of registering, through anLRM_RI_Registration Protocol (S10).

Here, specific information (or parameter or element) is exchangedbetween the LRM 300 and the RI 200, so that an Imported RO (RO to becreated by the LRM 300 in step S20) can be moved between the DRM Agentsvia the RI 200.

The LRM_RI_Registration Protocol of step S10 will be explained in moredetail.

The RI 200 may send a Trigger Message to the LRM 300 by using atechnique such as WAP Push (S11). The Trigger Message includes at leastone of an RI ID, an RI URL, an LRM ID, and the kind of a message to besent by the LRM. The kind of a message to be sent by the LRM is aRegistration Request Message (corresponding to step S12). The TriggerMessage in step S11 corresponds to an option. That is, the subsequentsteps (S12 and S13) may be executed without the step S1.

The LRM 300 receives the Trigger Message, then, accesses the RI 200 byusing a URL of the RI included in the Trigger Message, and sends aRegistration Request Message (LRM_RIRegistrationRequest in FIG. 5)(S12). Here, the LRM 300 may send the Registration Request Message byobtaining its user's (e.g., the first DRM Agent's user's) consent, e.g.,by displaying, on a display of the DRM Agent, whether to agree or not.However, without the step S11, the LRM 300 may send the RegistrationRequest Message by accessing the RI 200 (S12). Here, the LRM 300 maysend the Registration Request Message to the RI 200 by using apredefined (e.g., preset at the time of being shipped from factory) URLof the RI 200. The Registration Request Message in step S12 includes atleast one of an LRM ID, an RI ID, a message sending time (time when theRegistration Request Message was transmitted), a signature for theentire Registration Request Message, etc. The Registration RequestMessage may further include a certificate of the LRM 300, and/or a‘RequestToMoveRO’ parameter (or ‘NeedMoveService’ element. Here, the‘RequestToMoveRO’ parameter corresponds to a request that an Imported RO(created by the LRM 300) be later moved via the RI 200. The‘NeedMoveService’ element, if present, is used by the LRM to indicate tothe RI that the LRM needs the RI provides Move service for the ROscreated by the LRM, so that the ROs created by the LRM can be Moved viathe RI to other Devices.

The RI 200 processes the Registration Request Message, and sends aRegistration Response Message (LRM_RIRegistrationResponse in FIG. 5) tothe LRM 300 (S13). A method for processing the Registration RequestMessage by the RI 200 in step S13 will be explained in more detail.

Firstly, the RI 200 checks a signature of the received RegistrationRequest Message. If the Registration Request Message includes acertificate (LRM Cert) therein, the RI 200 checks that the LRM 300 hasbeen certified by its trustful certificate Authority. Then, the RI 200checks whether to revoke the LRM Cert or not, via a CRL or an OCSPprovided from the Certificate Authority (not shown in FIG. 5). Then, theRI 200 checks whether a ‘RequestToMoveRO’ parameter is included in theRegistration Request Message. According to whether or not a‘RequestToMoveRO’ parameter is included in the Registration RequestMessage, the RI 200 can check whether an RO to be created (or havingbeen created) by the LRM 300, i.e., an RO to be imported in step S20,can be later moved via the RI 200. The check is based on a contractbetween the LRM 300 and a manufacturing company, or a contract betweenthe LRM 300 and a user, or policies of a Content Provider that operatesthe RI 200. When the RI 200 allows the LRM 300 to provide a service tomove an RO (‘MoveRO’ service), the RI 200 stores an ID of the LRM 300 ina storage unit thereof. Here, the ID of the LRM 300 is used, when thefirst DRM Agent 400 requests the RI 200 of moving an RO to the secondDRM Agent 500, so as to check whether the requested RO can be moved (S40in FIG. 5).

Secondly, the RI 200 makes a Registration Response Message, and sends itto the LRM 300. Here, the Registration Response Message includes atleast one of information (status information) indicating whether theRegistration Request Message has succeeded or failed, an RI ID, an LRMID, and a signature for an entire message. When the Registration RequestMessage received by the RI 200 has failed (e.g., when the RI 200 can notprocess the Registration Request Message, or a certification has failed,etc.), the Registration Response Message may further include failurereasons. The Registration Response Message may include an ‘OkayToMoveRO’parameter (information or element). The ‘OkayToMoveRO’ parameterincludes information indicating a result of a check for a‘RequestToMoveRO’ parameter included in the Registration RequestMessage. That is, the ‘OkayToMoveRO’ (or ‘ProvideMoveService’) parameteris used by the RI to indicate to the LRM 300 whether the RI 200 willprovide Move service for the ROs that the LRM 300 creates.

The ‘OkayToMoveRO’ parameter (element) may be used in various ways. Ifthe ‘OkayToMoveRO’ element is present in rspinfo element inLRM-RIRegistrationResponse (i.e., Registration Response Message of S13),the LRM 300 may indicate within all the Imported-Rights-Objects that theLRM 300 creates that this particular RI 200 is eligible to move the RO.On the contrary, If the ‘OkayToMoveRO’ element is not present in rspinfoelement in LRM-RIRegistrationResponse (i.e., Registration ResponseMessage of S13), the LRM 200 shall not indicate within any Imported-ROthat the LRM 200 creates that this particular RI 200 is eligible to movethe Rights. Alternatively, the ‘OkayToMoveRO’ parameter may includeState Information into the Registration Response Message. Here, theState Information indicates whether an RO created by the LRM 300(Imported RO) can be moved between the DRM Agents. For instance, whenthe Status Information is set as ‘success’, it indicates that the‘OkayToMoveRO’ parameter is included in the Registration ResponseMessage. On the contrary, when the Status Information is set as‘failure’, it indicates that the ‘OkayToMoveRO’ parameter is notincluded in the Registration Response Message. The RI 200 makes aRegistration Response Message including information for an LRM_RIRegistration Protocol with the LRM 300, and sends it to the LRM 300.

The Trigger Message in S11 may correspond to an option. When sending theRegistration Request Message without the Trigger Message, the LRM 300may send the Registration Request Message to the RI 200 by using apredefined (e.g., preset at the time of being shipped from the factory)URL of the RI 200.

Hereinafter, the steps S20 and S30 will be explained in more detail.

Firstly, the LRM 300 imports a content from another DRM system (S20). Asa result, an Imported RO and a DRM content are created. If the LRM 300is permitted, by the RI 200, to move the created RO via the RI 200,information for later moving an RO via the RI 200 (‘RO movinginformation’) is included in the RO (RO created by the LRM). Here, the‘RO moving information’ includes at least one of an RI ID, an RI URL,and an LRM ID. The LRM 300 calculates a signature of the RO, and insertsit into the RO. That is, the RO (Imported RO) includes ‘RO movinginformation’ indicating that the RO can be moved to another DRM Agent(e.g., second DRM Agent) via the RI 200, a signature, an LRM ID, etc.The LRM ID is displayed inside the RO.

The LRM 300 moves the RO created in the step S20 (Imported RO) to thefirst DRM Agent through an LRM_Agent RO Protocol (S30).

Hereinafter, steps S40 and S50 will be explained.

If a user of the first DRM Agent 400 is to move an RO created by the LRM300 in step S20 (Imported RO) to the second DRM Agent 500, the first DRMAgent 400 sends the Imported RO (RO received from the LRM 300) to the RI200 by using a ROAP_Rights Moving Protocol with the RI 200 (S40). Here,when the RO is a Stateful RO, State Information of the RO may beadditionally sent.

More concretely, the first DRAM Agent 400 sends an ‘RO Moving RequestMessage’ to the RI 200 (S41). Here, the ‘RO Moving Request Message’ is‘RO moving information’, and includes at least one of an ID of the firstDRM Agent 400, an ID of the RI 200, a message sending time (time whenthe ‘RO Moving Request Message’ was transmitted), and an RO signed bythe LRM (Imported RO received from the LRM). If the RO is a Stateful RO,State Information of the RO is further included in the ‘RO MovingRequest Message’. The RO Moving Request Message may further include anMAC or a signature.

The RI 200 processes the RO Moving Request Message in step S41. Moreconcretely, the RI 200 checks a signature of the RO received from theLRM 300, that is, checks whether the LRM 300 that signed the RO has beenpermitted, by the RI 200 through an LRM_RI_Registration Protocol (S10),to move the RO. Here, the check by the RI 200 is performed by using anLRM ID inside the RO. That is, the RI 200 compares an LRM ID stored whenprocessing the Registration Request Message of S12, with an LRM IDinside the RO of S41. If the two LRM IDs are consistent to each other,the RI 200 determines that moving the RO is permitted.

The RI 200 creates an RO Moving Response Message, and sends it to thefirst DRM Agent 400 (S42). Here, the RO Moving Response Message includesat least one specific information, such as information indicatingwhether moving the RO of S41 has succeeded or failed, an ID of the RI200, and an ID of the first DRAM Agent 400. Here, the informationindicating whether moving the RO of S41 has succeeded or failed, isinformation indicating whether moving the RO is permitted as a result ofcomparing the two LRM IDs with each other. For instance, if the LRM IDsare consistent to each other (a successful check result), theinformation indicating whether moving the RO has succeeded or failed isset to include information indicating that moving the RO is permitted(Status=Success). On the contrary, if the LRM IDs are not consistent toeach other (an unsuccessful check result), the information indicatingwhether moving the RO has succeeded or failed is set to includeinformation indicating that moving the RO is not permitted(Status=Failure), or information indicating that an error is included inthe RO Moving Request Message. The RO Response Message may furtherinclude an MAC (MAC with respect to the entire RO Response Message)and/or a signature.

The first DRM Agent 400 receives the RO Moving Response Message from theRI 200, and checks whether an MAC or a signature is included in thereceived RO Moving Response Message (S42). If the RO Moving ResponseMessage includes information indicating that moving the RO has failed,the first DRM Agent 400 may inform to its user through an output device(e.g., display or speaker, etc. of the first DRM Agent).

If the RO Moving Response Message includes information indicating thatmoving the RO has succeeded, the RI 200 issues an RO to the second DRMAgent 500 by using an RO Acquisition Protocol (S50). The RO AcquisitionProtocol may be the conventional 1-pass or 2-pass RO AcquisitionProtocol, or 3-pass Confirmed RO Acquisition Protocol. The ROAcquisition Protocol of the step S50 corresponds to the conventionalart, so that its detailed explanation will be substituted by the ‘OMADRM 2.1 DRM Specification’.

Hereinafter, configurations and functions of the LRM 300 according tothe present invention will be explained.

The LRM 300 may create an RO imported from a content having beenreceived by itself from an external system, so as to be movable betweenDRM Agents. For this, the LRM 300 requests the RI 200 of moving an RO byusing an LRM_RI Registration Protocol, and receives a response from theRI 200. Here, the LRM 300 may request the RI 200 of moving an RO byincluding a ‘RequestToMoveRO’ parameter in the Registration RequestMessage, so that an Imported RO can be movable between DRM Agents viathe RI 200 (refer to S12 in FIG. 5). Then, the LRM 300 may check whetheran ‘OkayToMoveRO’ parameter (status information) is included in theRegistration Response Message, and check whether the RI 200 haspermitted the RO imported by the LRM 300 to be moveable between DRMAgents (refer to S12 in FIG. 5). If the RI has permitted the RO to bemoveable, the LRM 300 creates an RO from a content received from anexternal system, by including its ID (LRM ID) in the RO. The operationand functions of the LRM may be executed by a processor (or controller)of the LRM 300.

Here, the processor of the LRM 300 may be implemented by software, orhardware, or a module having a software, etc. Explanations for theoperation of the LRM 300 will be substituted by those aforementioned inFIGS. 4 and 5.

Hereinafter, the configurations and functions of the RI 200 of thepresent invention will be explained.

The RI 200 may manage rights of issuing RO imported by the LRM 300. Thatis, when the LRM 300 requests a moving of an RO, the RI, 200 may permitor reject a moving of an RO with consideration of system conditions anduser's policies (refer to S10 in FIG. 5). That is, the RI 200 may checka ‘ReqeustToMoveRO’ parameter included in the Registration RequestMessage sent from the LRM 300, and permit the request about moving an RObetween DRM Agents via the RI 200, by including an ‘OkayToMoveRO’parameter in a Registration Response Message. The RI 200 stores an LRMID in a storage unit thereof. Then, when receiving, from the first DRMAgent, a request about moving an RO (imported by the LRM) to the secondDRM Agent, the RI 200 extracts an LRM ID from the RO. Then, the RI 200compares the extracted LRM ID with the LRM ID stored therein. If the twoLRM IDs are consistent to each other, it is determined that the RI 200has permitted the LRM 300 to move the RO. Accordingly, the RI 200 movesthe RO to the second DRM Agent requested by the first DRM Agent. Theoperation and functions of the RI 200 may be executed by a processor (orcontroller) of the RI 200. Here, the processor of the RI 200 may beimplemented by software, or hardware, or a module having a software,etc. Explanations for the operation of the RI 200 will be substituted bythose aforementioned in FIGS. 4 and 5.

It will also be apparent to those skilled in the art that variousmodifications and variations can be made in the present inventionwithout departing from the spirit or scope of the invention. Thus, it isintended that the present invention cover modifications and variationsof this invention provided they come within the scope of the appendedclaims and their equivalents.

1. A method for moving Rights Object (RO), comprising: sending, by aFirst Entity, a Registration Request Message including first informationabout moving of an RO, to a Second Entity; receiving, by the FirstEntity, a Registration Response Message including second informationabout moving of an RO, from the Second Entity; importing, by the FirstEntity, an RO and a DRM content from digital contents received from anexternal system; and moving, by the First Entity, the Imported RO to aDRM Agent.
 2. The method of claim 1, further comprising: receiving, bythe First Entity, a Trigger Message for a protocol to be registered tothe Second Entity, from the Second Entity.
 3. The method of claim 1,wherein the RO comprises an ID of the First Entity.
 4. The method ofclaim 1, wherein the First Entity is a Local Rights Manager (LRM), andthe Second Entity is a Rights Issuer (RI).
 5. The method of claim 2,wherein the Trigger Message comprises at least one of an RI ID, an RIURL, an LRM ID, and information indicating the kind of an LRM message.6. The method of claim 1 wherein the first information comprises atleast one of a ‘RequestToMoveRO’, an RI ID, an LRM ID, a signature, amessage sending time, and an LRM Cert.
 7. The method of claim 6, whereinthe ‘RequestToMoveRO’ is a parameter including request information, bythe First Entity, about moving an Imported RO between DRM Agents via theSecond Entity.
 8. The method of claim 1, wherein the second informationcomprises at least one of an ‘OkayToMoveRO’, an RI ID, an LRM ID, asignature, a message sending time, and an LRM Cert.
 9. The method ofclaim 8, wherein the ‘OkayToMoveRO’ is a parameter including informationindicating that an RO created by the First Entity is permitted to bemoveable between DRM Agents via the Second Entity.
 10. A method formanaging rights of issuing Rights Object (RO), comprising: receiving, bya Second Entity, a Request Message about moving of an RO created by aFirst Entity, from the First Entity; checking, by the Second Entity,whether first information about moving of an RO has been included in theRequest Message; and when the Second Entity permits moving of an RO,sending, by the Second Entity, a Response Message including secondinformation about moving of an RO, to the First Entity.
 11. The methodof claim 10, wherein the First Entity is a Local Rights Manager (LRM),and the Second Entity is a Rights Issuer (RI).
 12. The method of claim10, wherein the first information comprises at least one of an LRM ID, a‘RequestToMoveRO’, an RI ID, a signature, a message sending time, and anLRM Cert.
 13. The method of claim 12, further comprising: checking, bythe Second Entity, whether a ‘RequestToMoveRO’ parameter has beenincluded in the Request Message; and storing, by the Second Entity, anID of the First Entity.
 14. The method of claim 12, wherein the‘RequestToMoveRO’ is a parameter including request information, by theFirst Entity, about moving an Imported RO between DRM Agents via theSecond Entity.
 15. The method of claim 10, wherein the secondinformation comprises at least one of an ‘OkayToMoveRO’, an RI ID, anLRM ID, a signature, a message sending time, and an LRM Cert.
 16. Themethod of claim 15, wherein the ‘OkayToMoveRO’ is a parameter includinginformation indicating that an RO created by the First Entity ispermitted to be moveable between DRM Agents via the Second Entity. 17.The method of claim 16, wherein the RO created by the First Entitycomprises an ID of the First Entity.
 18. The method of claim 13, furthercomprising: receiving, by the Second Entity, a Request Message aboutmoving of an RO to a second DRM Agent, from a first DRM Agent;extracting, by the Second Entity, an ID of the First Entity included inthe Request Message; checking, by the Second Entity, whether the storedID of the First Entity is consistent with the extracted ID of the FirstEntity; when the two IDs of the First Entity are consistent to eachother, sending, by the Second Entity, the Response Message to the firstDRM Agent; and moving, by the Second Entity, the RO to the second DRMAgent.
 19. A method for moving an imported Rights Object (RO),comprising: receiving, by a first DRM Agent, an RO from a Local RightsManager (LRM), wherein the RO is imported from contents which the LRMhas been received by from an external system; sending, by the first DRMAgent, an RO Moving Request Message, to an Rights Issuer (RI) so as tomove the RO to the second DRM Agent; and receiving, by the first DRMAgent, a Response Message about the RO Moving Request Message, from theRI.
 20. The method of claim 19, wherein the Request Message about movingan RO comprises at least one of an ID of the second DRM Agent, an RI ID,a message sending time, and an RO signed by the LRM, and wherein theRequest Message about moving an RO further comprises State Informationwhen the RO is Stateful.